home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000065_icon-group-sender _Tue Mar 4 01:41:06 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 4 Mar 1997 08:23:28 MST
  2. Date: Tue, 4 Mar 1997 01:41:06 -0600
  3. Message-Id: <199703040741.BAA05683@segfault.cs.utsa.edu>
  4. From: Clinton Jeffery <jeffery@segfault.cs.utsa.edu>
  5. To: espie@fregate.ens.fr
  6. Cc: icon-group@cs.arizona.edu
  7. In-Reply-To: <5f1r3u$b7l@nef.ens.fr> (espie@fregate.ens.fr)
  8. Subject: Re: Icon and two-dimensional matching
  9. Reply-To: jeffery@cs.utsa.edu
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 694
  13.  
  14.  
  15. [Marc Espie wrote:]
  16.  
  17. > I've got cases where everything ended up in one or two buckets,
  18. > or rather larger sets where the hashing process failed due to the
  19. > sheer size of the data.
  20.  
  21. Interesting.  I will agree that it might be useful to be able to specify
  22. your own hashing function.  It is true that tables with millions of elements
  23. use a LOT of memory.  But given a computer with enough memory the tables
  24. scale up very well to large size, thanks to work by Bill Griswold and
  25. Gregg Townsend.  The number of buckets increases dynamically.
  26.  
  27. Clint Jeffery
  28. jeffery@cs.utsa.edu
  29. Division of Computer Science, The University of Texas at San Antonio
  30. Research http://www.cs.utsa.edu/research/plss.html
  31.